fix: cap the connections a web listen serves at once - #693

web.listen spawned a task per accepted connection with no ceiling. a client
that opens connections faster than they complete grows the task count without
bound, and every green task carries a pooled stack, so that is memory growth
rather than scheduling pressure. listen_tls had the same gap — it runs its own
accept loop rather than delegating, so both plaintext and tls were uncapped.
listen_h2c was the odd one out: it delegates to std.net.http2.server and
inherited that module's cap, which meant one of the three web entry points was
bounded and two were not, with nothing in the api to say which.

refusing rather than blocking

the four http/2 accept loops block on a permit before spawning. that is the wrong
answer here, and the reason is the protocol rather than a preference.

an http/2 connection is a multiplexer. requests arrive on connections that are
already open, so a loop that stops accepting keeps serving requests at full rate
— including a health check on any established connection. blocking costs new
peers their connection and nothing else, which is what backpressure should cost.

http/1.1 has no such decoupling. a request needs a connection, and past the first
keep-alive burst a new request needs a new accept. a loop that stops accepting
stops answering everything: the load balancer's probe, the orchestrator's
liveness check, GET /healthz. the process is then killed for being
unresponsive at exactly the moment it is healthy and full, and the replacement
comes up into the same load. worse, the failure reports itself inconsistently —
a tcp-level probe still succeeds against a backlogged listener, so whether the
server looks alive depends on how it is measured.

so these loops accept and refuse: 503 Service Unavailable with Retry-After,
written inline on the accept loop, no task spawned. the memory the cap exists to
protect is still protected, because refusing costs one write and one close. over
tls the socket is closed instead — saying 503 in http would mean completing the
key exchange first, which is the expensive work being refused.

the 503 itself is best-effort, and the code says so rather than implying
otherwise. closing a socket that still holds unread data sends RST instead of
FIN, and a client that gets RST discards what it had buffered — so a peer that
had already sent its request, which is most of them at the moment a cap fires,
sees a connection error rather than the status line. draining the request first
is the fix and it is not available: a read on a socket whose peer sent nothing
has no deadline under the green runtime and would park the accept loop forever,
which is the failure the whole design is avoiding. the response can only improve
on the reset, never replace it, so the operator's signal is the counter and the
503 is a courtesy to the peers that happen to be waiting. the test exercises the
clean-FIN case and says which one it is.

the shape changes with the decision. connection_slots is a Semaphore, and a
semaphore's whole contribution over a counter is that acquire() waits; there is
no non-blocking way to take a permit. remove the waiting and what is left is a
counter, so this is an AtomicInt claimed with compare_set in a retry loop.
the claim still sits where #691 put the drain count — on the accept loop, before
the spawn — and is given back by the same defer on the connection task,
ordered to land before shutdown.leave() so a drain that reports zero has
already returned every slot.

against inert timeouts

tcp_set_timeout does nothing under the green runtime (the green read path waits
on the reactor with no deadline), so CONNECTION_TIMEOUT_MS does not reclaim the
slot of a connection that stalls. that is a separate bug and is not touched here,
but it decides how this design has to degrade. under a blocking cap a set of
stalled connections ends in a silent wedge: no accepts, no answers, nothing to
look at. refusing turns the same situation into a server that answers every
connection immediately, with a refusal counter climbing and a live-connection
gauge pinned at the cap — which is that wedge's exact signature, on a scrape.

observability

nothing in std.metrics covered the http/2 loops, so there was nothing to match.
two series are added, recorded by the accept loop rather than the request
middleware so a web.bare() app has them too:

• http_server_connections — a gauge of connections being served
• http_server_connections_refused_total — a counter of connections refused

the http/2 loops still expose neither.

what was tested

three colocated tests in std/web.pith, each run under PITH_GREEN=1 and
PITH_GREEN=0. they drive spawn_conn / spawn_tls_conn directly over real
socket pairs, the way the drain tests added in #691 do, so nothing waits for a
listener to bind and there is no sleep anywhere in them. holding 512 real sockets
open would cost more descriptors than a test should, so the counter is filled to
one below the cap through the same claim the accept loop uses and the two
connections that follow straddle it exactly.

• the cap binds, and does not block. at 511 held slots, two accepted
  connections: the first is admitted and appears in the drain count, the second
  is refused. the hand-off returning at all is the assertion — under a blocking
  cap the test never reaches the next line. the refused peer reads back a
  complete 503 Service Unavailable without having sent a request, the refusal
  counter moves by exactly one, and no second task or drain entry appears. then
  the held slots are dropped and a fresh connection is admitted and served
  pong, so the cap sheds load rather than latching.
• slots come back. six connections through spawn_conn, counter exact at +6
  the instant the last hand-off returns, each driven to a real pong, then
  drain(5000) == 0 and the counter back to its baseline. this is the leak case
  — a slot kept here shrinks the cap on every burst until the server refuses
  everything, hours later, with nothing to point at.
• tls. an admitted tls connection holds its slot from the accept, before its
  handshake has read a byte, and gives it back when the handshake fails after its
  peer disappears — the failure path, which is the one a hostile client picks.
  past the cap the socket is closed with no task, no drain count, and no
  handshake, and the peer reads end-of-stream rather than a server hello.

each was falsified against the code it claims to cover, on the default backend:

that last one is the design decision demonstrated: with the loop parked on a
slot, the test process stops answering entirely, which is what a blocked accept
loop does to a health check.

make run-regressions-only at 332/332, make docsite-check clean.